Skip to main content

​
Retry Policies

BindAI supports basic executor-level retry handling for workflow nodes when a retry policy is configured. However, retry behavior is only partially implemented. The current runtime supports a maximum-attempt limit, but does not yet apply configured retry delays or exponential backoff. Applications should understand these limitations before relying on automatic retries for operations that may fail.

​
Current Behavior

A workflow can configure a RetryPolicy with a maximum-attempt limit:
When a node execution raises an exception, the executor checks the configured retry policy.
  • If no retry policy is configured, the node failure is returned immediately.
  • If a retry policy is configured, the executor retries the failed node immediately.
  • If the attempt limit is reached, the workflow fails.
  • The retry counter resets after a successful node execution.
The retry counter applies to the current node. A value of max_attempts=3 allows up to three failed attempts for that node before the executor returns a failure, assuming the failures are handled by the retry mechanism. Retries do not currently wait between attempts.

​
Supported and Unsupported Features

The current retry implementation provides:
  • RetryPolicy configuration
  • Maximum-attempt handling
  • Automatic retry after a caught node execution exception
  • Retry-counter reset after successful execution
The following features are not currently implemented by the executor:
  • Configurable retry delays
  • Exponential backoff
  • Retry-specific workflow events
  • Configurable retryable exception types
  • A documented per-node retry configuration interface
The delay_seconds and exponential_backoff fields exist on RetryPolicy, but the executor does not currently use them. Setting these fields does not change retry timing. Applications should not assume that retries are delayed, that backoff is applied, or that only selected exception types will trigger retries.

​
Retry vs Loop

BindAI supports workflow loops. Loops and retries are different concepts. A loop repeats workflow logic as part of the workflow’s intended control flow:
A retry repeats a failed operation in response to an execution error:
A configured retry policy can provide the second behavior for node execution exceptions handled by the executor. It does not replace workflow loops or provide a general-purpose retry system for every kind of failure. For intentional repetition, use the implemented workflow loop functionality. For failure-triggered retries, configure a retry policy and account for its current limitations.

​
Failed Operations

A workflow may contain operations that fail during execution. For example:
Without a retry policy, a caught node execution exception results in failure. With a retry policy, the executor can repeat the node execution:
Retries occur immediately. The current implementation does not apply the configured retry delay or exponential backoff. Retry handling applies to exceptions caught by the executor’s retry mechanism. It should not be interpreted as a guarantee that every unsuccessful workflow operation will be retried.

​
External Services

External operations such as:
  • HTTP requests
  • Webhook calls
  • AI provider requests
  • Database operations
  • Other external integrations
may fail for transient or permanent reasons. A configured workflow retry policy can retry node execution when an exception reaches the executor’s retry handler. However, BindAI does not currently provide configurable retry delays, exponential backoff, or retryable-exception filtering. Applications should consider the consequences of repeating an operation. For example, retrying a request that performs a payment or creates a record may repeat a side effect if the original operation succeeded remotely but failed before its result was received. Where appropriate, use idempotency controls and application- or tool-level error handling.

​
Current BindAI V1 Scope

Basic retry handling is implemented in the workflow executor, but retry functionality remains limited. The current workflow control-flow capabilities include:
  • Conditions
  • Loops
  • Parallel execution
  • Join synchronization
  • Human Tasks
Retry policies provide an additional mechanism for retrying failed node executions, subject to the limitations described on this page.

​
Configuration Reference

The current RetryPolicy exposes these fields: Do not rely on delay_seconds or exponential_backoff to control retry timing until those behaviors are implemented. The availability of a configuration field does not necessarily mean that the runtime currently honors it.

​
Documentation Scope

This page documents only the retry behavior currently implemented and verified in the workflow runtime. It does not promise configurable backoff, delayed retries, exception filtering, or retry-specific workflow events. These capabilities should be documented as supported features only after their runtime behavior is implemented and verified.

​
Summary

BindAI supports basic executor-level retries for failed workflow node executions when a RetryPolicy is configured. The executor enforces the maximum-attempt limit and retries immediately. The configured delay and exponential-backoff fields are not currently applied. For intentional repetition of workflow logic, use Loop functionality. For failure-triggered retries, account for the limitations documented above.